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OVERVIEW 

SynTEAM  Federated  Internet  Architecture  (SFIA) 


SFLA  is  an  Internet  architecture  framework  that  will  support  federated  multi- 
operator  distributed  simulation  exercises,  as  well  as  corresponding  applieation 
development.  The  focus  of  this  effort  is  to  create  a  federated  internet  application  system 
that  will  integrate  existing  and  future  simulators  in  an  effort  to  create  a  scaled  joint 
battlespace  research  and  training  program.  The  immediate  goals  of  the  distributed 
internet  architecture  effort  is  to  delineate  the  components,  protocols,  and  program 
language  infrastructure  that  will  produce  a  system  of  platform  independent  tools  that  can 
serve  all  phases  of  distributed  internet  simulation,  from  exercise  planning  and 
development,  to  execution,  evaluation,  and  feedback.  SFIA  will  leverage  the  advanced 
intemet-H  strategic  alliance  program,  which  has  been  designed  to  facilitate  access  to 
current  and  future  highly  integrated,  digital  communications  services  for  education  and 
research.  Intemet-II  connectivity  will  provide  reliable  communications  system  with  the 
ability  to  integrate  high  performance  voice,  data  and  video  services  in  a  competitive 
multi-vendor  environment  at  reasonable  cost  and  with  a  quality  of  service  standard. 

Three  components  of  the  SFIA 

1.  Simulation  Authoring  System-  (SAS) 

2.  Integrative  Simulation  Management  Engine  (ISME) 

3.  Performance  Assessment  and  Debriefing  System  (PADS) 

1.  Simulation  Authoring  System-  (SAS) 

SAS  will  be  a  graphic  user  interface  tool-set  that  will  allow  rapid  scripting  of  multi¬ 
operator  exercises. 

SAS  will  be  composed  of  two  basic  modules: 

Object  database  that  will  provide  the  battlespace  entities,  as  well  as  define  their 
properties  and  features. 
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Scripting  program  that  will  support  scenario  planning  and  development,  scenario 
visualization,  and  battlespace  configuration. 

2.  Integrated  Simulation  Management  Engine  (ISME) 


ISME  will  provide  the  utilities  for  real-time  monitoring  of  scenario  execution,  messaging, 
data  collection  and  archiving,  as  well  as  other  technical  components  of  SFIA. 

ISME  will  rely  on  run-time  infrastructure  using  High  Level  Corba  Architecture,  which 
will  provide  wide-band,  high-speed  federated  control  over  scenario  actions.  The  run-time 
module  will  control  multi-cast  team  tasks,  provide  capabilities  to  query  and  analyze 
network  nodes,  and  furnish  alerts  on  networking  malfunctions. 

3.  Performance  Assessment  and  Debriefing  System  (PADS) 

PADS  will  be  composed  of  real-time  modeling  of  scenario  performance  data.  In 
addition,  it  will  offer  the  tools  for  offline  data  analysis.  PADS  will  leverage  cutting  edge 
data  visualization  techniques  including  integral  display  technology  and  immersive  3-D 
protocols. 


Joint  SynTEAM  Battle  Space  Program 
AHRP  Laboratory  Segment 
University  of  Georgia 

Task  Platforms 

UGA's  facet  of  SynTEAM  focuses  on  AW ACS  Weapons  Directors  with  highly 
configurable  fidelity  options.  In  addition,  other  domains  are  easily  added  to  the 
underlying  simulation  framework. 

Individual  or  Team 

Participants  may  work  either  individually  or  in  teams. 

How  Networked 

Networked  communication  uses  the  CORBA  protocol  and  the  Visibroker  ORB 
in  a  client-server  architecture.  Connections  to  federated  simulations  may 
be  implemented  with  adapters  at  the  server. 

Readiness  for  Internet  /  Internet2 

Architecture  relies  on  Internet  connectivity;  intranets  may  also  be 
used  if  DNS  service  is  available.  Because  UGA  is  an  Intemet2  partner, 
connections  to  other  Intemet2  institutions  are  automatically  routed 
through  Intemet2  backbones.  As  new  Intemet2  features  (e.g.,  IPv6,  QoS, 

CoS),  become  available,  SynTEAM's  modular  design  will  allow  us  to  begin 
using  them  quickly. 


Who  Can  Talk  to  Whom 


All  text  communication  between  participants  simulates  face  to  face 
Communication  between  WD's.  Although  communication  may  be  marked  for  a 
specific  individual,  everyone  "hears"  every  message. 

Voice  communication  currently  uses  embedded  Microsoft  NetMeeting 
technology,  again  simulating  face  to  face  communication.  Another  voice 
communication  system  using  RTF  and  JMF  is  under  construction.  The  new 
system  will  feature  configurable  bandwidth,  noise  levels,  and  data  archive. 

Communication  from  participants  to  simulated  entities  is  performed 
With  context-sensitive  menus.  Communication  from  entities  to  participants 
currently  comes  through  text  messages,  while  the  next  voice  communication  system 
will  also  allow  prerecorded  audio  entity-to-participant  messages. 

Relevance  to  Training 

SFIA  offers  an  easily  configurable  research  and  training  system  that,  in  theory,  can 
support  rapid  prototyping  through  its  modular  3-tier  architecture  design.  In  the  coming 
months,  the  platform  will  incorporate  a  number  of  experimental  protocols  and 
training/support  functions  (described  below). 


Performance  Measures 


A)  Embedded  Real-time  Support 
Individual 

a.  Signal  Detection-  simulation  solicited  events  for  discrete  choice 
points  to  model  an  operator’s  capacity  to  detect  a  signal  against 
background  of  noise.  [Individual  Outcome  and  some  Process] 

b.  Judgment  Analysis-  epoch-based  embedded  application  of  social 
judgment  theory  focusing  on  multi-sensor  values  and  operator  criterion 
judgments. 

c.  Information  integration-  Algorithm  configured  to  combine 
subjective  judgments  on  operational  parameters  in  a  fashion  analogous 

■  expected  utility.  [Individual  Outcome  and  Process] 

d.  Recognition  Primed  (RPD)-  Algorithm  for  collecting  response  data 
on  perceived  operational  context,  and  the  subsequent  action  policy 
executed  (similar  to  judgment  analysis).  [Individual  Process] 

e.  A  fuzzjTieuro  utility/controller  that  is  designed  to  detect 
fluctuations  in  decision  making  over  a  prescribed  decision  time-horizon  on 
the  basis  of  computed  moving  averages  in  a  number  of  behavioral  and 
cognitive  indices  such  as,  response  rate,  accuracy  with  external  criteria, 
response  consistency,  agreement  (team  measure),  cue  profile  matching 
indices,  and  error  distribution  values.  [Individual  Process  with  some 
Outcome] 


Team 


f.  TIDE^-  Epoch-based  assessment  relying  on  hierarchical  regression. 
[Team  Outcome  and  Team  Process] 

g.  Conflict/Constraint  Theory-  Focus  on  remediation  in  conflicting 
models  of  team  goals.  In  part  quantified  via  Judgment  analysis  protocols 
replacing  criterion  with  team-member  criterion  judgments.  [Team  Process] 

h.  Communication  Shared  Sampling  Methodology.  This  is  a 
modeling  technique  under  development  that  benchmarks  Team  Situational 
Awareness  via  modeling  team-task  communication  content. 

i.  Computational  simulation  methodology  for  predicting  Team  SA 
and  evaluating  team  member  attrition/tumover  on  team  functioning. 


Capabilities 

With  the  exception  of  the  fuzzyneuro  controller  that  is  essentially  passive,  the 
above  measures  require  event-driven  response  solicitations  executed  by  software  agents. 
Data  is  then  parsed  at  the  server  and  used  for  training  feedback  and/or  for  decision 
support  alerts.  Scenario  replay  is  supported. 

Research  Issues 

Individual  and  Team  Behavior 

Decision-making  effectiveness  depends  on  1)  task/mission  properties  (e.g.,  information 
quantity  and  complexity,  uncertainty  and  ambiguity),  as  well  as  other  ecological 
components  (e.g.,  workload,  time-of-day);  2)  representational  forms  and  interface 


engineering  protocols  (e.g.,  animated,  static,  morphing  displays),  3)  and  id  variables 
(expertise,  psychophysiological  state,  gender,  age,  etc.). 

SynTEAM  Technical  Overview 

SynTEAM’s  technical  infrastructure  was  designed  to  meet  three  primary  goals: 

•  Efficiency:  SynTEAM  should  be  able  to  run  on  minimal  client  machines.  The 
latest  Pentium  III  or  G4  processors  should  not  be  required. 

•  Power:  SynTEAM’s  design  should  facilitate  easy  incorporation  of  advanced 
performance  analysis  algorithms.  Because  many  of  these  algorithms  might 
require  intense  computation,  SynTEAM’s  design  should  be  easily  portable  to 
high-performance  server  hardware. 

•  Flexibility:  SynTEAM  should  allow  a  wide  range  of  possible  scenario  kits. 
Also,  administrators  must  be  able  to  configure  simulations  for  day-to-day  needs 
without  designing  completely  new  scenario  kits.  And  where  possible, 
SynTEAM  must  allow  for  eventual  extension  into  domains  beyond  AWACS 
weapons  direction. 

The  following  sections  will  describe  SynTEAM’s  technical  features  and  show  how  the 
three  design  goals  have  been  met. 


Industry  Standards 


Java 

•  All  major  components  of  SFIA/SynTEAM  are  written  in  Java,  a  software 
development  language  that  is  an  alternative  to  C/C++,  Ada,  or  Pascal. 

•  Unlike  other  languages,  Java  is  “write  once,  run  anywhere,”  reducing  long,  costly 
rewrites  when  porting  applications  to  other  platforms. 

•  Therefore,  while  SFIA/SynTEAM  was  developed  primarily  for  the  Windows 
family  of  operating  systems,  it  can  be  quickly  and  cheaply  ported  to  Macintosh, 
UNIX,  Linux,  Solaris,  and  other  systems. 

•  The  major  drawback  of  Java  compared  to  other  software  development  languages 
is  performance.  However,  SFIA’s  design  compensates  for  this  problem  by 
delegating  most  computationally  intensive  tasks  to  a  high  performance  server  and 
by  offering  customizable  realism  settings. 

CORBA 

•  CORBA  is  a  distributed  object  communications  protocol  similar  in  scope  to 
DCOM,  RMI,  and  HLA.  It  is  the  standard  mechanism  for  client-server 
communications  in  SFIA,  including  the  following: 

o  Joining  and  starting  simulations 
o  Battlespace  updates 
o  Transmitting  participants’  commands 


o 


Text  communication 


•  Standardized  by  the  largest  consortium  in  the  history  of  the  industry,  CORBA  is 
the  leading  distributed  object  communications  protocol.  This  ensures  support  and 
improvements  for  many  years  to  come. 

•  CORBA  allows  applications  written  in  different  languages  with  a  minimum  of 
development  time  and  cost.  Should  the  Java-based  server  application  be  replaced 
with  a  high-performance  C-based  application  in  the  future,  using  CORBA  ensures 
that  client  applications  will  still  function  without  change. 

•  In  SFIA/SynTEAM,  the  communications  system  is  extremely  modular.  So  if  the 
arises  to  switch  to  a  different  protocol  such  as  HLA,  the  transition  will  be 
relatively  fast  and  inexpensive. 

SynTEAM  Federated  Internet  Architecture 

Generalized  SynTEAM  Architecture 

•  Every  major  aspect  of  SynTEAM  has  been  designed  for  future  expandability. 

This  includes  simulation  of  other  domains  such  as  UAV,  complete  force  structure, 
and  business.  Thus,  all  aspects  of  SynTEAM  that  apply  to  all  types  of  continuous 
event  simulations  have  been  “factored  out”  into  a  separate  set  of  modules  called 
the  SynTEAM  Federated  Internet  Architecture  (SFIA): 
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Figure  1:  SFIA  Structure 


o  Communication  standards  between  participants,  intelligent  agents,  and 
simulated  entities  (see  CORBA  above), 
o  Distributed  simulation  logic  such  as  miniworld  maintenance  and 
distribution. 

o  Data  collection  and  analysis  procedures. 


Server  Duties 

•  As  shown  in  Figure  1,  most  computationally  intensive  tasks  are  performed  at  the 
server.  This  means  that  client  machines  need  to  meet  only  minimum  hardware 
requirements. 

•  The  server  maintains  the  battlespace  and  continually  updates  the  state  of 
simulated  entities  such  as  fighters,  tankers,  SAM  sites,  etc. 

•  The  server  also  offers  configural  realism  so  administrators  can  select  the  proper 
balance  between  realism  and  performance. 


Entity  Specification 


•  The  term  simulated  entity  refers  to  an  object  that  is  simulated  during  the  course  of 
a  SynTEAM  scenario,  such  as  a  tanker,  fighter  plane  or  air  base. 

•  Entities  are  organized  in  an  inheritance  hierarchy. 

o  The  use  of  an  inheritance 
hierarchy  allows 
developers  to  easily 
update  the  behavior  of 
many  simulated  entities 
simultaneously. 

o  For  example,  consider  the 
sample  inheritance 

Figure  2.  Example  Inheritance  Hierarchy 

hierarchy  in  Figure  2.  If 

a  developer  wants  to  add  a  more  realistic  fuel  consumption  algorithm  to  all 
simulated  airplanes,  he  or  she  has  only  to  change  the  behavior  of  the 
Aircraft  entity,  and  all  entities  hQlo'f/  Aircraft  in  the  hierarchy  will  inherit 
the  new  behavior. 

o  The  alternative  would  be  to  update  each  individual  plane.  As  SynTEAM 
matures,  this  might  mean  having  to  make  changes  to  hundreds  of 
individual  planes,  one  at  a  time. 

o  Thus,  the  use  of  an  inheritance  hierarchy  translates  into  a  lower  “cost  of 
ownership”  of  SynTEAM  during  the  platform’s  lifetime. 


•  Adapter  entities  can  serve  as  proxy  connections  to  other  sirhulation  technologies 
such  as  HLA,  ModSAF,  and  JSAF.  Complete  HLA/ModSAF  compliance  can  be 
achieved  by  switching  the  communications  layer  from  CORBA  to  HLA. 

Data  Collection 

•  Data  logs  in  SFIA/SynTEAM  can  be  saved  in  one  of  two  formats:  verbal  or 
numeric.  The  numeric  format  is  ideal  for  use  with  statistical  analysis  software 
packages,  while  the  human-readable  verbal  format  is  useful  for  discovering 
complex  patterns. 

•  A  conversion  application  is  provided  to  translate  numeric  logs  into  the  verbal 
format. 

•  The  server  always  saves  a  “legend”  that  defines  all  symbols  used  in  the  numeric 
log.  This  legend  can  be  stored  with  the  log  so  that  future  researchers  and  trainers 
can  understand  the  logs  even  if  the  SFIA  applications  are  not  available. 

•  The  numeric  log  format  is  designed  to  be  easily  imported  into  analysis  packages 
such  as  Excel,  SPSS,  and  SAS. 

•  What  is  saved: 

o  Participants’  commands  to: 

■  Simulated  entities  (target,  orbit,  RTB) 

■  Other  participants  (text  communication) 

■  GUI  display  (zoom,  declutter) 
o  All  command  execution  styles 

■  Keyboard,  menu  bar,  context  menus,  mouse 


■  This  unique  feature  is  essential  for  research  on  interface  designs 
and  their  impact  on  SA. 

o  Automation 

■  Scripted  events 

■  Entity-generated  commands  (shoot  down,  exit  miniworld) 
o  Triggered  comments  to  record  domain-specific  events 

•  All  data  events  are  time-stamps  to  within  1ms  or  the  highest  resolution  of  the 
computer. 

•  If  a  simulation  is  interrupted  by  an  error,  an  error  log  is  generated  that  saves 
information  to  help  developers  identify  and  remove  any  bugs. 

AWACS  Miniworld 


Entity  Behavior 

•  Although  SynTEAM  is  not  designed  to  be  an  ultra-high  fidelity  simulator,  every 
effort  is  being  made  to  imbue  the  simulated  entities  with  psychologically  realistic 
behavior. 

•  Wherever  possible,  entity  attributes  such  as  maximum  airspeed,  optimum 
airspeed,  fuel  capacity,  fuel  consumption,  and  fuel  transfer  rate  are  based  on 
declassified  data  on  the  actual  vehicles.  Sources  include  Mathieu  Dalrymple  at 
Brooks  AFB  and  United  States  Military  Aircraft  Since  1909  by  Gordon 
Swanborough  and  Peter  M.  Bowers. 

•  Examples: 


o  F-15 


■  Maximum  speed:  1600  nmph 

■  Optimal  speed:  620  nmph 

■  Optimal  altitude:  40000  f 

■  Fuel  capacity:  20916  lb 

■  Fuel  consumption  rate:  224  Ib/min 
o  F-16 

■  Maximum  speed:  1600  nmph 

■  Optimal  speed:  580  nmph 

■  Optimal  altitude:  32000  f 

■  Fuel  capacity:  6972  lb 

■  Fuel  consumption  rate:  112  Ib/min 
o  KC-135R  Tanker 

■  Maximum  speed:  585  nmph 

■  Optimal  speed:  380  nmph 

■  Optimal  altitude:  27,000f 

■  Fuel  capacity:  120,000  lb 

■  Flies  in  “cells”  of  3  tankers  awaiting  other  aircraft  in  need  of  refueling. 

•  However,  if  a  scenario  should  require  the  simulation  of  an  entity  that  does  not 
conform  to  normal  specifications,  all  entity  attributes  are  easily  configurable. 

Terrain 

•  AWACS  simulations  have  taken  several  different  approaches  to  the  representation 
and  storage  of  terrain  on  the  radar  view.  Two  common  approaches  have  been 
rejected  for  SynTEAM  because  of  various  faults: 


o  Raster  approaches  represent  terrain  in  a  bitmap  format  such  as  GIF  or 
JPEG.  But  raster  formats  have  large  storage  requirements,  both  on  disk 
and  in  RAM.  Furthermore,  zooming  with  raster  formats  is 
computationally  intensive,  and  terrain  quickly  becomes  jagged  and 
unrecognizable  at  higher  zoom  levels.  Finally,  raster-based  terrain 
displays  bear  little  resemblance  to  real  AW  ACS  displays, 
o  Arc-based  approaches  represent  terrain  as  a  system  of  intersecting  circles 
that  overlap  to  form  irregular  terrain  shapes.  While  arc-based  formats 
have  much  lower  storage  and  processing  requirements  than  raster  formats, 
terrain  creation  is  difficult  and  counter-intuitive.  Also,  arc -based  based 
terrain  looks  markedly  different  from  actual  AW  ACS  terrain  display. 
Vector-based  terrain,  the  approach  used  in  SynTEAM  as  well  as  real  AW  ACS 
displays,  is  represented  as  complex  polygons.  Like  the  arc-based  approach,  the 
vector-based  approach  has  very  low  storage  and  processing  requirements,  but  the 
vector-based  format  allows  for  much  more  complex  and  realistic  terrain  outlines. 
Vector-based  terrain  creation  is  quick  and  intuitive. 


Client  Facilities 


The  radar  view  is  SynTEAM’s  primary  view  into  the  battlespace.  SynTEAM’s 
radar  view  uses  standard  track  icons  and  vector-based  terrain  display.  The  screen 
is  mouse-aware,  allowing  the  WD  to  select  tracks  with  the  left  button  and  send 


Figure  3:  Client  Screen 


commands  to  entities  with  context-sensitive  menus  brought  up  with  the  right 
button. 

The  declutter  controls  allow  WD’s  to  change  the  amount  and  type  of  information 
on  the  radar  screen.  Display  of  grid  lines  (both  major  and  minor),  terrain,  and 


track  names  can  be  controlled  here. 


•  The  overhead  view  shows  a  fully  zoomed-out  view  of  the  hattlespace.  It  can  be 
used  to  compensate  for  the  typical  PC  monitor’s  smaller  size  compared  to  a  real 
AWCAS  radar  screen. 

•  The  track  information  window  displays  all  known  characteristics  about  the 
selected  radar  track.  Categories  are  adjusted  according  to  the  track  type  and  the 
data  access  of  the  WD. 

•  The  simulation  time  cell  shows  the  time  within  the  simulation.  The  display  is 
necessary  because  SynTEAM’s  time  compression  feature  allows  administrators  to 
run  scenarios  faster  or  slower  than  real  time. 

•  The  text  communication  window  presents  participant-to-participant  and  entity- 
to-participant  messages.  Although  this  functionality  will  eventually  be  replaced 
by  audio  messages,  the  relative  immaturity  of  voice-over-IP  technology  dictates 
that  SynTEAM  retain  text  information  capability  for  the  time  being. 

Administrator  Facilities 

Scenario  Kit  Generator 

•  Most  low-  to  mid-fidelity  AW  ACS  simulators  use  encoded  text  files  to  store 
scenario  kit  information.  The  coding  schemes  used  by  these  simulators  are  often 
so  cryptic  that  only  developers — not  users — can  create  scenario  kits.  Coded  text 
files  are  also  extremely  error-prone. 

•  SynTEAM’s  Scenario  Kit  Generator  allows  WYSIWYG  creation  of  AWACS 
scenarios  in  the  same  visual  paradigm  used  by  trainers  in  the  field  today. 


o  Initial  Force  Layout:  Using  a  drag-and-drop  interface,  administrators 
can  visually  lay  down  the  initial  force  structure  in  the  main  window. 


File 

D  I  1^  I  H  I 


'Command . 

Time:  0:Q:0;0,  Command;  Target,  Entity  ID;  9.  Target  ID:  4 
Time:  0:1;0;0,  Command:  Move  To.  Entity  ID'  9.  Location;  50,0.00,0 
Time;  0;  1:3:0,  Command:  Comment.  Text  Examine  SA  here. 


A 

F15 
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FI  6 

A 

^wacs 

A 

JStars 

Tanker 
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AifBase 

A 

SamSrta 

O 

Point 

HUne 
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VUna 

Add 

Edit 

Delete 

TWs  radar  screen  Is  600M  x  600M  X;  -1 38  Y:  70 


Figure  4:  Scenario  Kit  Generator 

o  Scenario  Script:  Here,  administrators  can  enter  simulation  events  in 
easy-to-use  forms.  Unlike  older  systems  that  use  text-based  scripts,  the 
Scenario  Kit  Generator  checks  scripts  for  errors  before  running  a 
simulation,  streamlining  the  kit  development  time. 


Runtime  Scenario  Configuration 

•  Scenario  Kit  Choice:  Administrators  can  choose  one  of  the  installed  scenario 


kits  from  a  drop-down  list  box. 


•  Time  Compression:  Often, 
the  normal  time-course  of  an 
AWACS  simulation  is  too 
slow  for  a  given  research  or 
training  need,  with  long 
stretches  of  inactivity 
between  decision  points.  The 
normal  time-course  can  also 
be  too  slow,  particularly  for 
training,  forcing  an 

inexperienced  trainee  to  cope 
with  unfamiliar  tactical  5:  Administrator  Configuration  Screen 

problems  that  emerge  too  quickly.  To  deal  with  both  of  these  situations, 
SynTEAM  allows  the  administrator  to  set  the  ratio  of  simulation  time  to  real  time. 

•  Feedback  Interval:  Because  delayed,  intermittent  feedback  can  have  a  very 
important  impact  on  performance,  administrators  can  use  this  option  to  set  radar 
sweep  intervals  to  times  other  than  the  default  12  seconds. 

•  Participant  Number:  Finally,  administrators  can  set  the  number  of  human 
participants  in  the  simulation. 

Real  Time  Analysis 

•  Zoom  View  SA  Agent:  SFIA/SynTEAM’s  architecture  was  designed  to  allow 
quick,  easy  implementation  of  a  number  of  performance,  decision,  and  SA 
analysis  algorithms.  The  Zoom  View  SA  Agent  is  the  first  prototype,  designed  to 


monitor  the  time  each  participant  spends  at  high  zoom  levels.  Because  high  zoom 
levels  limit  the  total  amount  of  battlespace  information  that  is  displayed,  spending 
too  long  at  a  high  zoom  level  can  lead  to  reduced  SA.  Should  a  participant 
exceed  a  preset  limit  of  continuous  zoom-in  time,  the  Agent  will  alert  the 
administrator. 


University  of  Georgia 
Athens,  Georgia 
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SynTEAM  Technology 


SynTEAM  Design  Goals 

•  Efficiency 

-  Runs  on  minimal  client  machines 

•  Power 

-  Easy  addition  of  measurement  algorithms 

-  Hooks  for  high  performance  server 

•  Flexibility 

-  Wide  array  of  possible  scenario  kits 

-  Highly  configurable  simulation  parameters 

-  Wide  array  of  possible  simulation  domains 


Outline 


•  Overall  architecture 


•  Industry  standard  foundations  incorporating 
evolving  technologies 

•  SynTEAM  Federated  Internet  Architecture 
(SFIA):  Generalized  distributed  simulation 
framework 

•  AWACS  implementation 


Overall  SynTEAM  Architecture 


Domain  Information  & 
Entity  Behavior 

Distributed 
Simulation  & 
Measurement 


Java,  CORBA, 
RTF,  JMF 


Industry  Standards:  CORBA 


•  Distributed  computing  protocol 

-  Defines  how  server  &  clients  communicate 


•  Uses  in  SynTEAM 

-  Joining  &  starting  simulations 

-  Battlespace  updates 

-  Transmitting  participants’  commands 


CORBA  Benefits 

•  Shorter,  cheaper  development  cycles 

•  Not  language-dependent 

-  Can  change  server  code  without  changing  clients 

-  Easy  to  replace  server  code  with  high  performance  language 
for  complex  measurement 

-  Opens  the  way  for  SFIA  &  object  databases 

•  SynTEAM’s  modular  design  allows  easy  protocol 
changes 


Industry  Standards:  RTP 


•  Real-time  Transport  Protocol 

•  Used  for  audio  &  video  conferencing 

•  Current  audio  conferencing  implementations 

-  Java  Media  Framework 

•  Java  standard 

•  Legal  &  performance  problems  with  beta  test  code 

•  Finalized  last  week 

-  Microsoft  NetMeeting 

•  Works  great 

•  Platform  specific 

•  Prototyping  only 


SFIA: 

General  SynTEAM  Architecture 


•  Not  specific  to  AWACS 

•  Communication  standards 


-  Participants,  entities,  intelligent  agents 

•  Distributed  simulation  logic 

•  Data  collection 

•  Allows  extension  to  other  domains 


UAV,  complete  force  structure,  civilian  aerospace, 
business 


SFIA: 

General  SynTEAM  Architecture 
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SFIA: 

General  SynTEAM  Features 


•  Simulation  Engine 

-  Maintains  simulated  world  (battlespace) 

-  Continually  updates  entities  (planes,  SAMs,  etc.) 

-  Configurable  realism:  Realism  vs.  performance 

•  Entity  Specification 

-  Defines  how  to  create  new  entities 

-  Supports  addition  of  features  to  support  research 

•  Intelligent  agents,  weather,  vehicles 


SFIA  Audio  Conferencing 


•  One  “Net  4”  channel 

•  All  audio  recorded  (after  move  to  JMF) 

•  Save  separate  or  merged  audio  streams 
-  Server  performance  vs.  research  need 

•  Configurable  bandwidth  /  noise  levels 

•  Hooks  to  add  automated  messages  &  alerts 

•  Current  use  of  NetMeeting  for  prototyping  only 


SFIA  Scripting  Facility 

•  Defines  initial  scenario  kit  setup 

•  Controls  events  in  simulated  world 


-  Popups,  scrambles,  flight  paths 

•  Hooks  to  add  “branching”  scripts  in  future 

-  Conditional  branching  to  predetermined  sets  of 
events 


SynTEAM  Technology 

•  Power 

-  Easy  addition  of  measurement  algorithms 

-  Hooks  for  high  performance  server 

•  Flexibility 

-  Wide  array  of  possible  scenario  kits 

-  Highly  configurable  simulation  parameters 

-  Non-AWACS  implementations 

•  Efficiency 

-  Runs  on  minimal  client  machines 
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From  AH  ARP  (Advanced  Human  Research  Project) 

Re:  Conference  meeting  with  Computer  Science 
OVERVIEW 

SynTEAM  Federated  Internet  Architecture  (SFIA) 

SFIA  is  an  Internet  architecture  framework  that  will  support  federated  multi¬ 
operator  distributed  simulation  exercises,  as  well  as  corresponding  application 
development.  The  focus  of  this  effort  is  to  create  a  federated  internet  application  system 
that  will  integrate  existing  and  future  simulators  in  an  effort  to  create  a  scaled  joint 
battlespace  research  and  training  program.  The  immediate  goals  of  the  distributed 
internet  architecture  effort  is  to  delineate  the  components,  protocols,  and  program 
language  infrastructure  that  will  produce  a  system  of  platform  independent  tools  that  can 
serve  all  phases  of  distributed  internet  simulation,  from  exercise  planning  and 
development,  to  execution,  evaluation,  and  feedback.  SFIA  will  leverage  the  advanced 
intemet-II  strategic  alliance  program,  which  has  been  designed  to  facilitate  access  to 
current  and  future  highly  integrated,  digital  communications  services  for  education  and 
research.  Intemet-II  connectivity  will  provide  reliable  communications  system  with  the 
ability  to  integrate  high  performance  voice,  data  and  video  services  in  a  competitive 
multi-vendor  environment  at  reasonable  cost  and  with  a  quality  of  service  standard. 

Three  components  of  the  SFIA 

1.  Simulation  Authoring  System-  (SAS) 

2.  Integrative  Simulation  Management  Engine  (ISME) 

3.  Performance  Assessment  and  Debriefing  System  (PADS) 

1 .  Simulation  Authoring  System-  (SAS) 

SAS  will  be  a  graphic  user  interface  tool-set  that  will  allow  rapid  scripting  of  multi¬ 
operator  exercises. 

SAS  will  be  composed  of  two  basic  modules; 

Object  database  that  will  provide  the  battlespace  entities,  as  well  as  define  their 
properties  and  features. 

Scripting  program  that  will  support  scenario  planning  and  development,  scenario 
visualization,  and  battlespace  configuration. 

2.  Integrated  Simulation  Management  Engine  (ISME) 


ISME  will  provide  the  utilities  for  real-time  monitoring  of  scenario  execution,  messaging, 
data  collection  and  archiving,  as  well  as  other  technical  components  of  SFIA. 

ISME  will  rely  on  run-time  infrastructure  using  High  Level  Corba  Architecture,  which 
will  provide  wide-band,  high-speed  federated  control  over  scenario  actions.  The  run-time 
module  will  control  multi-cast  team  tasks,  provide  capabilities  to  query  and  analyze 
network  nodes,  and  furnish  alerts  on  networking  malfunctions. 

3.  Performance  Assessment  and  Debriefing  System  (PADS) 

PADS  will  be  composed  of  real-time  modeling  of  scenario  performance  data.  In 
addition,  it  will  offer  the  tools  for  offline  data  analysis.  PADS  will  leverage  cutting  edge 
data  visualization  techniques  including  integral  display  technology  and  immersive  3-D 
protocols. 
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1  □  SynTEAM  Technology 

AHRP  Lab 
University  of  Georgia 
December  2000 

2  □  SynTEAM  Design  Goals 

•  Efficiency 

-  Runs  on  minimal  client  machines 

•  Power 

-  Easy  addition  of  measurement  algorithms 

-  Hooks  for  high  performance  server 

•  Flexibility 

-  Wide  array  of  possible  scenario  kits 

-  Highly  configurable  simulation  parameters 
~  Wide  array  of  possible  simulation  domains 

3Q  Outline 

•  Overall  architecture 

•  Industry  standard  foundations  incorporating  evolving  technologies 

•  SynTEAM  Federated  Internet  Architecture  (SFIA):  Generalized  distributed  simulation 
framework 

•  AW  ACS  implementation 

Overall  SynTEAM  Architecture 

Industry  Standard  Foundations 

•  Java 

-  Computer  language,  like  C++,  Pascal,  or  BASIC 

-  *Write  once,  run  anywhere" 

-  Realistically,  much  shorter  development  cycles 

-  Windows  9x  &  NT,  Macintosh,  *NIX  (Linux,  AIX,  Solaris,  etc,),  legacy  machines 

-  Drawback:  Speed  (SFIA  accommodates  this) 

Industry  Standard  Foundations 
Industry  Standards:  CORBA 

•  Distributed  computing  protocol 

-  Defines  how  server  &  clients  communicate 

•  Uses  in  SynTEAM 

-  Joining  &  Starting  simulations 

-  Battlespace  updates 

-  Transmitting  participants’ commands 

-  Text  communication 

8  □  CORBA  Benefits 

•  Shorter,  cheaper  development  cycles 

•  Not  language-dependent 

-  Can  change  server  code  without  changing  clients 

-  Easy  to  replace  server  code  with  high  performance  language  for  complex  measurement 

-  Opens  the  way  for  SFIA  &  object  databases 

•  SynTEAM's  modular  design  allows  easy  protocol  changes 

9Q  Industry  Standards:  RTF 

•  Real-time  Transport  Protocol 

•  Used  for  audio  &  video  conferencing 

•  Current  audio  conferencing  implementations 


-  Java  Media  Framework 

•  Java  standard 

•  Legal  &  pedormanca  problems  with  beta  test  code 

•  Rnalized  last  week 

-  Microsoft  NetMeeting 

•  Works  great 

•  Platform  specific 

•  Prototyping  only 


10  □  SFIA: 

General  SynTEAM  Architecture 

•  Not  specific  to  AW  ACS 

•  Communication  standards 

-  Participants,  entities,  intelligent  agents 

•  Distributed  simulation  logic 

•  Data  collection 

•  Allows  extension  to  other  domains 

UAV,  complete  force  structure,  civilian  aerospace,  business 

11  □  SFIA: 

General  SynTEAM  Architecture 

12  □  SFIA: 

General  SynTEAM  Features 

•  Simulation  Engine 

-  Maintains  simulated  world  (battlespace) 

-  Continually  updates  entities  (planes,  SAMs,  etc.) 

-  Configurable  realism:  Realism  vs.  performance 

•  Entity  Specification 

-  Defines  how  to  create  new  entities 

-  Supports  addition  of  features  to  support  research 

•  intelligent  agents,  weather,  vehicles 

13  Q  SFIA  Data  Collection 

•  Numeric  and  verbal  formats 

~  For  analysis  or  “eyeballing" 

•  Translation  of  numeric  to  verbal  format 

•  Saves  a  legend  for  numeric  format 

•  Loads  directly  into  Excel,  SPSS,  SAS,  etc. 

w  Q  What  is  Recorded 

•  Participants’  commands  to... 

-  Entities  (target,  orbit,  RTB) 

-  Other  participants  (text  communication) 

-  GUI  display  (zoom,  declutter) 

•  All  command  styles 

-  Keyboard,  menu  bar,  context  menu,  buttons 

•  Automation 

-  Scripted  events 

-  Entity-generated  commands  (shot  down,  left  world) 

15  □  What  is  Recorded 

•  All  data  time  stamped 

-  To  1  ms  or  resolution  of  computer 


•  Error  log 


-  Accelerates  bug  detection  &  removal 

16  □  SFIA  Audio  Conferencing 

•  One  “Net  4"  channel 

•  All  audio  recorded  (after  move  to  JMF) 

•  Save  separate  or  merged  audio  streams 

-  Server  performance  vs.  research  need 

•  Configurable  bandwidth  /  noise  levels  , 

•  Hooks  to  add  automated  messages  &  alerts 

•  Current  use  of  NetMeeting  for  prototyping  only 

17  Q  SFIA  Scripting  Facility 

•  Defines  initial  scenario  kit  setup 

•  Controls  events  in  simulated  world 

-  Popups,  scrambles,  flight  paths 

•  Hooks  to  add  “branching”  scripts  in  future 

-  Conditional  branching  to  predetermined  sets  of  events 

18  □  SFIA  Scripting  Facility 

•  Further  configuration  available  at  runtime 

-  Realism  vs.  performance 

-  Time  compression 

-  Number  of  participants 

•  Numerically  coded  text  files 

•  Migration  to  GUI  scripting  tool 

19  Q  AWACS-SpecIfic  SynTEAM 

•  Entities  organized  In  hierarchical  inheritance  tree 

•  Quick  and  easy  to  alter  entities 

•  Easy  to  add  new  entities 

•  Paves  the  way  to  object  databases  in  SFIA 

20  □  AWACS-Specific  Actions 

Q]  •  Target 

•  Orbit 

•  Pursue 

•  Refuel 

•  Return  to  base 

•  Zoom 

@  •  Change  label 

•  Display  label 

•  Show  /  hide  grid  lines 

•  View  plane  stats 

•  Set  reference  point 

•  Joker  &  Bingo  Calls 

21  □  SynTEAM  Technology 

•  Power 

-  Easy  addition  of  measurement  algorithms 

-  Hooks  for  high  performance  server 

•  Flexibility 

-  Wide  array  of  possible  scenario  kits 

-  Highly  configurable  simulation  parameters 

-  Non-AWACS  implementations 


Efficiency 

-  Runs  on  minimal  client  machines 


